<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns='http://www.w3.org/1999/xhtml'>
<head><title>HTTP/1.1: HTTP Message</title></head>
<body><address>part of <a rev='Section' href='rfc2616.html'>Hypertext Transfer Protocol -- HTTP/1.1</a><br />
RFC 2616 Fielding, et al.</address>
<h2><a id='sec4'>4</a> HTTP Message</h2>
<h3><a id='sec4.1'>4.1</a> Message Types</h3>
<p>
   HTTP messages consist of requests from client to server and responses
   from server to client.
</p>
<pre>       HTTP-message   = Request | Response     ; HTTP/1.1 messages
</pre>
<p>
   Request (section 5) and Response (section 6) messages use the generic
   message format of RFC 822 [9] for transferring entities (the payload
   of the message). Both types of message consist of a start-line, zero
   or more header fields (also known as "headers"), an empty line (i.e.,
   a line with nothing preceding the CRLF) indicating the end of the
   header fields, and possibly a message-body.
</p>
<pre>        generic-message = start-line
                          *(message-header CRLF)
                          CRLF
                          [ message-body ]
        start-line      = Request-Line | Status-Line
</pre>
<p>
   In the interest of robustness, servers SHOULD ignore any empty
   line(s) received where a Request-Line is expected. In other words, if
   the server is reading the protocol stream at the beginning of a
   message and receives a CRLF first, it should ignore the CRLF.
</p>
<p>
   Certain buggy HTTP/1.0 client implementations generate extra CRLF's
   after a POST request. To restate what is explicitly forbidden by the
   BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
   extra CRLF.
</p>
<h3><a id='sec4.2'>4.2</a> Message Headers</h3>
<p>
   HTTP header fields, which include general-header (section <a rel='xref' href='rfc2616-sec4.html#sec4.5'>4.5</a>),
   request-header (section 5.3), response-header (section 6.2), and
   entity-header (section <a rel='xref' href='rfc2616-sec7.html#sec7.1'>7.1</a>) fields, follow the same generic format as
   that given in Section <a rel='xref' href='rfc2616-sec3.html#sec3.1'>3.1</a> of RFC 822 <a rel='bibref' href='rfc2616-sec17.html#bib9'>[9]</a>. Each header field consists
   of a name followed by a colon (":") and the field value. Field names
   are case-insensitive. The field value MAY be preceded by any amount
   of LWS, though a single SP is preferred. Header fields can be
   extended over multiple lines by preceding each extra line with at
   least one SP or HT. Applications ought to follow "common form", where
   one is known or indicated, when generating HTTP constructs, since
   there might exist some implementations that fail to accept anything
</p>
<p>
   beyond the common forms.
</p>
<pre>       message-header = field-name ":" [ field-value ]
       field-name     = token
       field-value    = *( field-content | LWS )
       field-content  = &lt;the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, separators, and quoted-string>
</pre>
<p>
   The field-content does not include any leading or trailing LWS:
   linear white space occurring before the first non-whitespace
   character of the field-value or after the last non-whitespace
   character of the field-value. Such leading or trailing LWS MAY be
   removed without changing the semantics of the field value. Any LWS
   that occurs between field-content MAY be replaced with a single SP
   before interpreting the field value or forwarding the message
   downstream.
</p>
<p>
   The order in which header fields with differing field names are
   received is not significant. However, it is "good practice" to send
   general-header fields first, followed by request-header or response-
   header fields, and ending with the entity-header fields.
</p>
<p>
   Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.
</p>
<h3><a id='sec4.3'>4.3</a> Message Body</h3>
<p>
   The message-body (if any) of an HTTP message is used to carry the
   entity-body associated with the request or response. The message-body
   differs from the entity-body only when a transfer-coding has been
   applied, as indicated by the Transfer-Encoding header field (section
   <a rel='xref' href='rfc2616-sec14.html#sec14.41'>14.41</a>).
</p>
<pre>       message-body = entity-body
                    | &lt;entity-body encoded as per Transfer-Encoding>
</pre>
<p>
   Transfer-Encoding MUST be used to indicate any transfer-codings
   applied by an application to ensure safe and proper transfer of the
   message. Transfer-Encoding is a property of the message, not of the
</p>
<p>
   entity, and thus MAY be added or removed by any application along the
   request/response chain. (However, section 3.6 places restrictions on
   when certain transfer-codings may be used.)
</p>
<p>
   The rules for when a message-body is allowed in a message differ for
   requests and responses.
</p>
<p>
   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length or Transfer-Encoding header field in
   the request's message-headers. A message-body MUST NOT be included in
   a request if the specification of the request method (section <a rel='xref' href='rfc2616-sec5.html#sec5.1.1'>5.1.1</a>)
   does not allow sending an entity-body in requests. A server SHOULD
   read and forward a message-body on any request; if the request method
   does not include defined semantics for an entity-body, then the
   message-body SHOULD be ignored when handling the request.
</p>
<p>
   For response messages, whether or not a message-body is included with
   a message is dependent on both the request method and the response
   status code (section <a rel='xref' href='rfc2616-sec6.html#sec6.1.1'>6.1.1</a>). All responses to the HEAD request method
   MUST NOT include a message-body, even though the presence of entity-
   header fields might lead one to believe they do. All 1xx
   (informational), 204 (no content), and 304 (not modified) responses
   MUST NOT include a message-body. All other responses do include a
   message-body, although it MAY be of zero length.
</p>
<h3><a id='sec4.4'>4.4</a> Message Length</h3>
<p>
   The transfer-length of a message is the length of the message-body as
   it appears in the message; that is, after any transfer-codings have
   been applied. When a message-body is included with a message, the
   transfer-length of that body is determined by one of the following
   (in order of precedence):
</p>
<p>
   1.Any response message which "MUST NOT" include a message-body (such
     as the 1xx, 204, and 304 responses and any response to a HEAD
     request) is always terminated by the first empty line after the
     header fields, regardless of the entity-header fields present in
     the message.
</p>
<p>
   2.If a Transfer-Encoding header field (section <a rel='xref' href='rfc2616-sec14.html#sec14.41'>14.41</a>) is present and
     has any value other than "identity", then the transfer-length is
     defined by use of the "chunked" transfer-coding (section <a rel='xref' href='rfc2616-sec3.html#sec3.6'>3.6</a>),
     unless the message is terminated by closing the connection.
</p>
<p>
   3.If a Content-Length header field (section <a rel='xref' href='rfc2616-sec14.html#sec14.13'>14.13</a>) is present, its
     decimal value in OCTETs represents both the entity-length and the
     transfer-length. The Content-Length header field MUST NOT be sent
     if these two lengths are different (i.e., if a Transfer-Encoding
</p>
<pre>     header field is present). If a message is received with both a
     Transfer-Encoding header field and a Content-Length header field,
     the latter MUST be ignored.
</pre>
<p>
   4.If the message uses the media type "multipart/byteranges", and the
     transfer-length is not otherwise specified, then this self-
     delimiting media type defines the transfer-length. This media type
     MUST NOT be used unless the sender knows that the recipient can parse
     it; the presence in a request of a Range header with multiple byte-
     range specifiers from a <a rel='xref' href='rfc2616-sec1.html#sec1.1'>1.1</a>
     client implies that the client can parse multipart/byteranges responses.
</p>
<pre>       A range header might be forwarded by a 1.0 proxy that does not
       understand multipart/byteranges; in this case the server MUST
       delimit the message using methods defined in items 1,3 or 5 of
       this section.
</pre>
<p>
   5.By the server closing the connection. (Closing the connection
     cannot be used to indicate the end of a request body, since that
     would leave no possibility for the server to send back a response.)
</p>
<p>
   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
   containing a message-body MUST include a valid Content-Length header
   field unless the server is known to be HTTP/1.1 compliant. If a
   request contains a message-body and a Content-Length is not given,
   the server SHOULD respond with 400 (bad request) if it cannot
   determine the length of the message, or with 411 (length required) if
   it wishes to insist on receiving a valid Content-Length.
</p>
<p>
   All HTTP/1.1 applications that receive entities MUST accept the
   "chunked" transfer-coding (section 3.6), thus allowing this mechanism
   to be used for messages when the message length cannot be determined
   in advance.
</p>
<p>
   Messages MUST NOT include both a Content-Length header field and a
   non-identity transfer-coding. If the message does include a non-
   identity transfer-coding, the Content-Length MUST be ignored.
</p>
<p>
   When a Content-Length is given in a message where a message-body is
   allowed, its field value MUST exactly match the number of OCTETs in
   the message-body. HTTP/1.1 user agents MUST notify the user when an
   invalid length is received and detected.
</p>
<h3><a id='sec4.5'>4.5</a> General Header Fields</h3>
<p>
   There are a few header fields which have general applicability for
   both request and response messages, but which do not apply to the
   entity being transferred. These header fields apply only to the
</p>
<p>
   message being transmitted.
</p>
<pre>       general-header = Cache-Control            ; Section 14.9
                      | Connection               ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.10'>14.10</a>
                      | Date                     ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.18'>14.18</a>
                      | Pragma                   ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.32'>14.32</a>
                      | Trailer                  ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.40'>14.40</a>
                      | Transfer-Encoding        ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.41'>14.41</a>
                      | Upgrade                  ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.42'>14.42</a>
                      | Via                      ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.45'>14.45</a>
                      | Warning                  ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.46'>14.46</a>
</pre>
<p>
   General-header field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields may be given the semantics of general
   header fields if all parties in the communication recognize them to
   be general-header fields. Unrecognized header fields are treated as
   entity-header fields.
</p>
</body></html>
